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SPECIFICATION 

TO ALL WHOM IT MAY CONCERN: 

Be it known that we, Ervin Dennis Walter, a citizen of the 
United States, residing at 1351 South Street, No. 16, Madison 53715, in the 
County of Dane and State of Wisconsin, and Mukesh Allu, a citizen of India, 
residing at 5826 Raymond Road, Apt. 2E, Madison 53711, in the County of 
Dane and State of Wisconsin, and Scott Andrew Lordi, a citizen of the 
United States, residing at 21 North Butler Street, Apt. 307, Madison 53703, 
in the County of Dane and State of Wisconsin, and Gary Stanton Holmes, a 
citizen of the United States, residing at S5811 Sugar Road, North Freedom 
53951, in the County of Dane and State of Wisconsin, and Carl David 
Dvorak, a citizen of the United States, residing at 9113 Aspen Grove Lane, 
Madison 53717, in the County of Dane and State of Wisconsin, and 


Joel Erick Rod, a citizen of the United States, residing at 234 Randolph 
Drive, #221 D, Madison 53717, in the County of Dane and State of 
Wisconsin, and Sumit Singh Rana, a citizen of India, residing at 6702 
Schroeder Road, #23, Madison 53711, in the County of Dane and State of 
Wisconsin, and Samit Govind Sureka, a citizen of India, residing at 6902 
Schroeder Road, Apt. 16, Madison 53711, in the County of Dane and State 
of Wisconsin, have invented a new and useful "Patient Health Record 
Access System," of which the following is a specification. 


PATIENT HEALTH RECORD ACCESS SYSTEM 


Cross-Reference to Related Applications 

This applications claims priority to United States Provisional Patent 
Application Serial No. 60/214,219, entitled "Integrated Patient and Enterprise Health 
Record System," filed June 26, 2000 (attorney docket no. 29794/36547), the 
disclosure of which is hereby expressly incorporated herein by reference. 

Field of the Invention 

The present invention relates generally to health records management, and 
more particularly, to a system for providing a patient with access to the patient's 
health record. 

Background of the Invention 

A variety of Internet-based systems for providing access to a patient's health 
record and related healthcare information have been proposed. Such Internet-based 
personal or patient medical records either provide patients access only to information 
that they enter and maintain themselves, or provide them with delayed and limited 
access to information contained in a separate healthcare information system from 
which patient health information must be abstracted and uploaded to a web server in 
regularly scheduled batch processes. A patient is unsure if the information they are 
viewing is the most up to date and complete. Apart from the ability to view selected 
portions of information or patient self-generated information, the proposed systems 
have not provided an effective forum to allow the patient to communicate with their 


health care providers. None of the proposed systems feature secured, real-time access 
to an integrated patient health record. 

Thus, there is a need for a patient health record access system that provides 
real-time communication between the patient and an integrated Patient Health Record 
5 (PHR) and an Enterprise Health Information System (EHIS). Such a system would 
provide patients with the most up-to-date information. Moreover, patients could avail 
themselves of electronic health-related services in real-time. Furthermore, a real- 
time, integrated PHR/EHIS system could provide efficiency, workflow flexibility and 
connectivity between patients and their health care providers and affiliated staff that 
1 0 are not available using previously disclosed systems. 


Brief Description of the Drawings 

FIG. 1 is a system block diagram of a patient health record access system in 
1 5 accordance with a preferred embodiment of the invention. 

FIG. 2 is a flowchart illustrating operation of the system illustrated in FIG. 1. 

FIG. 3 is a flowchart illustrating operation of a content relevancy engine 
portion of the system illustrated in FIG. 1 . 

FIG. 4 is a flowchart illustrating operation of the system illustrated in FIG. 1 
20 for viewing of information by the patient. 

FIG. 5 is a flowchart illustrating operation of the system illustrated in FIG. 1 
for processing messages. 

FIG. 6 is a flowchart illustrating operation of the system illustrated in FIG. 1 
for accepting and recording information from a patient. 
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FIG. 7 is a flowchart illustrating operation of the system illustrated in FIG. 1 
for scheduling appointments in accordance with a preferred embodiment of the 
invention. 

FIG. 8 is a flowchart illustrating operation of the system illustrated in FIG. 1 
5 for scheduling appointments in accordance with another preferred embodiment of the 
invention. 

FIG. 9 is a flowchart illustrating operation of the system illustrated in FIG. 1 
for providing class enrollment. 

FIG. 10 is a flowchart illustrating operation of the system illustrated in FIG. 1 
1 0 for p aying bills . 

Detailed Description of the Preferred Embodiments 

An integrated system provides patients with secure, real-time access to their 
1 5 Personal Health Record and an Enterprise Health Information System (PHR and 
EHIS, respectively). Access may be provided by way of the Internet and via a 
Personal Health Portal (PHP) web page. From the secure PHP web page, patients can 
view information created and maintained by their health care providers and their 
affiliated staff. The patients can also request services and information from their 
20 health care providers and affiliated staff, directly access EHIS-related services, such 
as scheduling an appointment, paying a bill, enrolling in a class, completing insurance 
and other forms, and viewing information and Internet services that are relevant to 
their particular health status. 

In a preferred embodiment of the invention a patient health record data server, 
25 including a machine-readable media having a data structure containing patient-created 
data, is coupled by a communication network with a patient interface. The 
communication network may be the Internet and the patient interface may be a 
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suitable Internet access device including a browser for supporting a personalized web 
page. A secure interface securely couples, in real-time, the patient health record 
server to an enterprise health record system for providing access by the patient to 
patient-related data retained within the enterprise health record system. Thus, the 
5 patient, via the patient interface, may access the patient health record server for 

manipulating the patient-created data and for accessing the patient-related data from 
the enterprise health record system. 

While described in terms of several preferred embodiments, it will be 
appreciated that the invention is not limited in scope to the embodiments herein 

1 0 described. Many modifications, alterations and additions may be made without 
departing from the fair scope of the invention. 

Referring to FIG. 1 of the drawings, a patient access system 10 includes a 
Patient Health Record (PHR) data server 12 and an EHIS data server 14. The PHR 
data server 12 maybe any suitable platform including processing, memory and data 

1 5 storage capability to perform the functions herein described. The PHR data server 1 2 
stores data entered by the patient within a data structure configured within the storage 
portion of the PHR data server 12. A secure interface or EHIS queue 16 securely 
couples the PHR server 12 and the EHIS data server 14 for communication of data 
and information from the PHR data server 12 to the EHIS data server 14. The EHIS 

20 Queue 16 provides a real-time secure communication link for information moving 

from the PHR data server 12 to the EHIS data server 14. This queue is used to transfer 
information for secure messaging and self-service options. In response to information 
received from the PHP web page, the PHR data server 12 forwards information to the 
EHIS queue 16. Information in the EHIS queue 16 is then processed appropriately by 

25 the EHIS data server 1 4. 
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While the specific configuration of the EHIS data server 14 is not particular to 
the structure and function of the present invention, preferably, the EHIS data server 
14 is a single data repository structured to support both the separation and the sharing 
of data. As such, the EHIS data server 14 may receive information from existing 
5 outpatient and inpatient data management systems via interfaces or from various 
integrated applications. The EHIS data server 14 maybe configured to organize 
information into a consistent whole to provide a longitudinal patient record. For 
example, the EHIS data server 14 may be linked to manage all aspects of a patient's 
hospital health status and care and to support effective management of patient lists, 

10 results inquiry management, complete clinical documentation, physician order entry 
with decision support, nursing workflow and documentation, and discharge planning. 
The EHIS data server 14 may further be configured to support the inclusion of 
problem lists, order communications, results reporting, pharmacy management, quick 
documentation, clinical messaging and communication. Additionally, the EHIS data 

1 5 server may be configured to manage referral information, up-to-date progress notes, 
lab results, discharge instructions, portions of a patient's record, and emergency 
summary cards. A suitable data management product that may be adapted as the 
EHIS data server 14 is the Epicenter® Enterprise Data Repository and related suite of 
products available from Epic System Corporation of Madison, Wisconsin. 

20 The PHR data server 12 includes a patient services application layer 22, a 

communication layer 24, a patient data manager 26 and a content relevancy engine 
28, all of which are suitably linked within an architecture for operation under the 
direction of the PHR data server 12. The patient data manager 26 includes suitable 
storage capability, such as magnetic, optical, or other storage technology, for storing 

25 patient-created data. The patient services application layer 22 and the communication 
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layer 24 include routines for managing access and use of the patient-created data, as 
well as to provide patient services. The PHR data server 12 is further linked, by way 
of the content relevancy engine 28 to a source of generic data 30 and a source of 
news, educational and similar materials 32 via a secure connection 34, such as a 
5 Internet protocol secure (IPsec) connection or by a file transfer protocol (ftp) 
connection. 

A communication network 36 couples the PHR data server 12 to a patient 
interface 38. The communication network 36 may include the Internet 40 or other 
suitable data network, and the PHR data server 12 is linked to the Internet 40 by a 

10 web server 42 in a highly secure dual firewall configuration. In this arrangement, a 
primary fire wall 44 protects the web server 42 and a secondary fire wall 46 protects 
the PHR data server 12 and the EHIS data server 14 with a communication link 48 
coupling the communication network 36 to the PHR data server 12. 

In a preferred embodiment of the invention, a shadow server 50 is provided 

1 5 and maintains a copy of at least the patient-related data retained within the EHIS data 
server 14. A communication link 52 permits the copying of the patient-related data 
from the EHIS data server 14 to the shadow server 50, and a view access only 
communication link 56 couples the shadow server 50 to the communication network 
36, and hence to the patient interface 38. This arrangement advantageously allows the 

20 EHIS data server 14 to be highly available for EHIS systems operation. Alternatively, 
the communication network 36 may be directly linked to the EHIS data server 14. 

Patients access the system 10 by logging into the web server 42 via the patient 
interface 38. The patient interface 38 is preferably configured as a web page 
displayed within a web browser running on a suitable platform, and is further 

25 preferably configured as a personalized Personal Health Portal (PHP) web page 
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providing the patient with patient-specific information and links to the features and 
services offered by the invention. The web server 42 may be any suitable web server 
platform containing routines for displaying the PHP web page and for managing 
online communication between a user logged in via an associated PHP web page and 
5 the PHR data server 12 and the EHIS data server 14. 

A user logging into the system via the PHP web page may or may not be an 
existing patient of the healthcare enterprise. For existing patient users, the PHR data 
server 12 may already contain a record for the patient, and, as will be described, the 
user is provided access to the information contained in that record. Some existing 

1 0 patients and new patients may not have a record within the PHR data server 12. 

These patients will have at least two options for gaining access to the functionality of 
the system 10. First, the patient may fully register by providing appropriate 
identifying. The PHR data server 12 creates a patient record for the user. 

A patient may gain access without fully identifying himself or herself. The 

1 5 patient may enter patient data using a user name and identifying information that is 

anonymous in nature. Access for this "anonymous user" may be limited to predefined 
functionality. For example, the anonymous user may be permitted only to view 
information related to services provide by the healthcare enterprise, may be able to 
create a record or patient created information within the PHR data server 12, maybe 

20 able to ask questions of the healthcare enterprise and receive responses, and the like. 
The anonymous user, however, would not be permitted to make appointments or 
request specific services of the healthcare enterprise. Additionally, should the 
anonymous user become a patient of the healthcare enterprise, the PHR data server 12 
may use the anonymous user record to create a patient record within the PHR data 

25 server 12 without requiring the patient to reenter information. 


7 


Operation and use of the system is described in more detail with reference to 
FIGS. 2-10. The flowcharts depicted in FIGS. 2-10 are linked and illustrate the 
operation of the system 10 in accordance with a preferred embodiment of the 
invention. The alpha designations indicate the interconnections between the various 
5 flowcharts depicted in the figures. Turning to FIG. 2 depicted is a method 200 of 
providing access by a patient to the PHR data server 12 and the EHIS data server 14. 
The method 200 begins at step 202 where the patient accesses a public web page, such 
as an Internet service provider (ISP) home page, with a PHP web page option and 
selects the PHP web page option, step 204. At step 206, the user attempts to log into 

1 0 the PHP web page, which is provided by the web server 42, using a suitable 

authentication technology. The web server 42 executes the authentication routine at 
step 208, and a user authorization determination is made at step 210. If the user is not 
authorized, the user is returned to the public web page. If the user is authorized, the 
content relevancy engine 28 functions, step 212, as will be described in connection 

15 with FIG. 3, and at step 214, the web server 42 generates and displays the user's PHP 
web page on the patient interface 38. 

From the PHP web page, the user is provided a selection of links providing 
access to patient-relevant content, information from the patient's enterprise health 
record, and services associated with the enterprise health information system. If the 

20 user does not click on a link within a timeout period causes the web server 42, at step 
216, to log the user out and to return the user to the public page. 

At step 2 1 8 the user clicks a content link. Depending on the type of content 
selected by the user, step 220, if the item is stored directly in a content database or on 
the web server 42, at step 224 the content is displayed on the PHP web page. 


Otherwise, for items stored as URLs, at step 226 the data retrieval and display option 
associated with the link opens a separate browser page to display the content. 

In a preferred embodiment of the invention, the user may also select: a view 
option; a secure messaging option, an edit or add notes option; an online form; 
5 schedule a prequalified appointment option; schedule an appointment option; enroll in 
a class option; pay a bill option or log out, respectively, links associated with blocks 
228-244. 

Referring now to FIG. 3, the content relevancy engine 28 operates in 
accordance with a method 300 depicted therein. At step 302, the web server 42 

10 requests patient-related information from the Shadow Server 14 and caches it on the 
PHR data server 12. This data includes the user's sex, age, zip code, medical 
problems and diagnoses (using ICD9 codes), procedures (using CPT codes) and 
medications (using GPI & NDC) as indicated at block 306. At step 304, another 
routine on the PHR data server 12 uses page layout specifications associated with the 

1 5 user's PHP web page, which may be specified by the system provider or may be user 
configurable, to determine what types of content to display, and how many items to 
display of each type. At step 308, for each type of content specified by the page 
layout, a routine within the content relevancy engine 28 compares the patient-related 
data to criteria in the content database. The content database is maintained on the 

20 PHR data server 12 and stores available content for display on the PHP web page with 
each record being categorized by display type, relevance factors, and effective dates 
as indicated at block 310. The content relevancy engine 28 at step 312 then 
determines if a content item is relevant based upon the cached patient-related 
information. At step 314, the content relevancy engine 28 then produces a ranked list 

25 of relevant content items, based on a number of matches between the content criteria 
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and the patient-related information. Then, at step 316, the web server 42 builds the 
PHP web page according to the page layout (step 308), using the highest-ranking 
content items for each type of content. 

When the user selects a link associated with a view option, secure messaging 
5 option, or self-service option, the PHR data server 12 initiates a routine associated 
with the link. Link 228 in FIG. 2 initiates a view content routine 400 illustrated in 
FIG. 4. The system 10 advantageously permits viewing of a wide variety of 
information types including patient-created information stored within the PHR data 
server 12 and patient-related information stored within the EHIS data server 14. The 

1 0 patient-created data may be notes and comments relating to the user's health or 
requests for information. The patient-related information may be portions of the 
user's medical record and other information created by the health care professionals 
and staff. In the preferred embodiment illustrated in FIG. 4, the user may select to 
view a health summary, a medication list, lab results, health reminders, recent visit 

1 5 information, medical history, upcoming appointments, messages, immunization 
information, allergies information, current health issues, financial and insurance 
information, and records access by selecting an appropriate link associated with the 
requested information represented by blocks 402-424, respectively. Upon the user 
selecting the link, at step 426 the web server 42 receives the data request, and at step 

20 428 initiates a routine to retrieve the requested information, either from the PHR data 
server 12 or the shadow server 50 (or EHIS data server 14 if so configured). At step 
430, the web server 42 updates the PHP web page with the new information. The web 
server 42 may retrieve the patient-related information from the shadow server 50 in 
XML format as shown in block 432. Similarly, the web server 42 may retrieve the 
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patient-created information from the PHR data server 12 in XML format, the patient- 
created information including user-entered notes or messages. 

The system 10 provides ability for the user to send and receive secure 
messages to the user's health care providers and administrators. Selecting the link 
5 230 in FIG. 2 initiates a secure messaging routine 500 illustrated in FIG. 5. The 
message types include a request for medical advice; a request for prescription 
renewal; a request for a referral; a customer service request; a request for a pre- 
qualified appointment and a request for an appointment, and the user selects the 
message type by selecting an appropriate link associated with the message type 

10 represented by blocks 502-5 12, respectively. Responsive to the user selecting one of 
the links 502-512, at step 514, the web server 42 creates a secure messaging form on 
the PHP web page for the selected message type. At step 516, the user enters the 
appropriate data and information into the message form. The user may cancel the 
message, step 518, and be returned to the previous PFIP web page, or the user clicks 

1 5 send, step 522. The web server 42 forwards the information to the PHR server 12, 

step 524, and the PHR server 12 places the user's message in a queue for transmission 
to the EHIS data server 14. At step 528, the EHIS data server 14 receives the 
incoming message from the queue, and translates and routes the message to the 
appropriate destination, and at step 530, the web server 42 updates the PHP web page 

20 to reflect that the user's message has been sent. 

Selecting the link associated with block 232 (FIG. 2) allows the user to add 
notes to the patient-created information, and selecting the link associated with the 
block 234 allows the user to complete forms. Selecting either link 232 or 234 initiates 
a process 600 illustrated in FIG. 6. Additionally, the user may add information flags 

25 to the patient-created information and/or other information contained with the PHR 
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server 12. The information flag identifies the flagged information and may provide 
read only access of the information to one or more of the user's health care 
professionals and staff. Coupled with the information flag, the PHR server 12 is 
adapted to generate an alert that is communicated to the EHIS data server 14 
5 indicating the receipt of the flag. Appropriate messaging may also be generated and 
communicated to the one or more of the user's health care professionals and staff. 

If the user has selected the link associated with block 232, the web server 42 
creates an add/edit notes form and displays the form on the PHP web page. At step 
604, the user enters or edits the note text in an editing window. If the user selects 

10 cancel, step 606, the notes/edits are discarded and the web server 42 returns to the 
previously displayed PHP web page. If the user clicks to save changes, step 610, the 
web server 42 forwards the edited text to the PHR data server 12, step 612, and the 
PHR data server 12 updates the patients notes portion of the patient-created date 
stored within the PHR data server 12, step 614. The user notes may be unstructured 

1 5 information, such as unstructured text notes, or the notes may be structured 
information. As an example, to input structured information the user may be 
presented with a form seeking particular information, such as medications they are 
currently taking or procedures they have had or will have. The fields within the form 
may be linked to other data entries in the enterprise health record system, such as 

20 reference materials for the entered medication or procedure. Moreover, the 

information need not be clinical in nature, as described in foregoing examples, but 
may be administrative in nature, such as benefits information. 

A similar process occurs if the user has selected the link associated with block 
234. The web server 42 creates an online form, such as an insurance form or medical 

25 history form, and displays the form on the PHP web page, step 616. At step 618, the 
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user enters information into the form in an editing window. If the user selects cancel, 
step 620, the information and form are discarded and the web server 42 returns to the 
previously displayed PHP web page, step 608. If the user clicks to save changes, step 
622, the web server 42 forwards the edited form to the PHR data server 12, step 624, 
5 and the PHR data server 1 2 forwards the information from the edited form to the 

EHIS server 50, step 626, where it is processed appropriately. The web server 42 then 
returns the user to the previous PHP web page, step 608. 

By selecting the link associated with the block 236 (FIG. 2) the user may 
schedule a prequalified appointment in accordance with a process 700 illustrated in 

10 FIG. 7. Upon selecting the link, the web server 42 queries the shadow server 50 for a 
list of available appointments for the current user, step 702. Whether prequalified 
appointments are available will depend on the existence of a scheduling ticket 
illustrated at 704. The scheduling ticket is provided by the shadow server 50 
responsive to input received from a care provider and specifies which providers are 

1 5 available, what procedures are required and dates and times that the appointment may 
be scheduled. If there are appointments available, step 706, the web server 42 updates 
the PHP web page with a listing of the appointments, step 708. At step 710, the user 
selects an appointment to schedule and, if necessary, provides additional information 
necessary to narrow the search for dates, times, etc. The user may also cancel the 

20 process at step 712, and web server 42 returns the user to the PHP web page. 

Otherwise, at step 714, the PHR data server 12 requests available appointments from 
a scheduling engine portion (not depicted) of the shadow server 50. If there are no 
appointments that meet the user specified criteria, step 716, the web server 42 updates 
the PHP web page, and the user is requested to enter revised information. Otherwise, 

25 at step 718 the web server 42 displays the list of available appointment times on the 
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PHP web page. At step 720, the user selects an appointment, and the web server 42 
forwards the appointment selection to PHR data server 12, which places the request in 
the EHIS queue 16 for processing by the EHIS data server 14. When the appointment 
is booked, the updated appointment information flows via the shadow server 54 from 
5 the EHIS data server 14 to the web server, which updates the PHP web page with the 
selected appointment summary information, step 728. The web server 42 also 
updates the scheduling ticket to reflect that a prequalified appointment has been 
scheduled. The user may otherwise cancel the scheduled appointment at step 722 and 
be returned to the PHP web page. 

10 A second appointment option is initiated by selecting the link associated with 

block 238 (FIG. 2), which starts a process 800 illustrated in FIG. 8. After the user 
selects the link 238, the web server 42 queries the shadow server 50 for a list of 
available providers for the user, step 802. At step 804, the web server 42 updates the 
PHP web page with a list of the providers. At step 806, the user selects a provider and 

15 provides additional information, such as dates and times for the appointment. The 
user may also cancel, step 808, and the web server 42 returns the user to the PHP web 
page. Otherwise, at step 810 the PHR data server 12 requests available appointments 
information from the scheduling engine portion of the shadow server 50. If there are 
no appointments within the date and time range provided by the user, step 812, the 

20 web server 42 updates the PHP web page for the user to provide additional 

information. Otherwise, the web server 42 updates the PHP web page with a list of 
the available appointments, step 814. At step 816, the user selects an appointment or 
cancels the process, step 818. If an appointment is requested, the web server 42 
forwards the appointment information to the PHR data server 12, which places the 

25 information in the EHIS queue 16 for processing by the EHIS data server 14. When 
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the appointment is booked, the updated appointment information flows via the 
shadow server 54 from the EHIS data server 14 to the web server, which updates the 
PHP web page with the selected appointment summary information, step 822. 

By the user selecting the link associated with block 240 (FIG. 2) a process 900 
5 illustrated in FIG. 9 is started that allows the user to enroll in a class. After the user 
selects the link 240, the web server 42 queries the shadow server 50 for a list of 
available classes for the user, step 902. At step 904, the web server 42 updates the 
PHP web page with a list of the classes. At step 906, the user selects a class or 
cancels the process, step 908. If the user cancels the process, the web server 42 

10 returns the user to the PHP web page. Otherwise, at step 910 the PHR data server 12 
requests available class times from the scheduling engine portion of the shadow server 
50. At step 912, the web server 42 displays the list of available class times, and at 
step 914 the user selects a class time or cancels. If an appointment is requested, the 
web server 42 forwards the appointment information to the PHR data server 12, which 

15 places the information in the EHIS queue 16 for processing by the EHIS data server 
1 4. When the appointment is booked, the updated appointment information flows via 
the shadow server 54 from the EHIS data server 14 to the web server, which updates 
the PHP web page with the selected appointment summary information, step 920. If 
the process is cancelled, the web server 42 returns the user to the PHP web page. 

20 By selecting the link associated with the block 242 (FIG. 2) the user may 

initiate a process 1000 illustrated in FIG. 10 for paying a bill. The process 1000 
begins at step 1002 with the web server 42 making a query of the shadow server 50 
for accounts for the user. The web server 42 at step 1004 updates the PHP web page 
with an accounts listing. The user may select an account at step 1006, or may cancel, 

25 step 1008. If the user cancels, the web server 42 returns the user to the PHP web 
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page, step 1010. If the user does select an account, at step 1012 a routine on the PHR 
data server 12 requests information from an accounts receivable engine portion (not 
depicted) of the shadow server 50. The account is checked to determine if there is an 
outstanding balance, step 1014. The user may then return to the PHP web page 
5 providing the account listing. The user may elect to pay all or a portion of any 
balance due or may elect to pay ahead to develop an account credit toward an 
upcoming procedure. To permit the user to make a payment, the web server 42 
displays a pay online option for the account, step 1016. The user may click the pay 
online option, step 1018, and the web server updates the PHP web page with an online 

10 payment form, step 1020. The user completes the online payment form, step 1022, or 
the user may cancel the process, step 1024 and be returned to the PHP web page. At 
step 1026, the web server 42 forward the information from the completed payment 
form to the PHR data server 12, which places the information in the EHIS queue 16 
for processing by the EHIS data server 14. When the payment is processed by the 

1 5 EHIS data server, the information flows via the shadow server to the web server 42, 
which updates the PHP web page 38 with a message indicating that the payment has 
been submitted, step 1028. The invention has been described in terms of several 
preferred embodiments, including a number of features and functions. Not all 
features and functions are required for every embodiment of the invention, and in this 

20 manner the invention provides a flexible system by which a user may access patient 
records, send and receive messages, retrieve information, schedule appointments, 
renew prescriptions, pay bills and the like. The features discussed herein are intended 
to be illustrative of those features that may be implemented; however, such features 
should not be considered exhaustive of all possible features that may be implemented 
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in a system configured in accordance with the preferred embodiments of the 
invention. 
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